This application relates to shared data store implementations, such as a mailbox or public folders, and more particularly, to a client side based data synchronization and storage solution to problems currently facing such shared data store implementations.
In a typical shared data store implementation, such as a mailbox or public folders, the updated data store structure and the contents are kept available and updated by a server. The clients' document stores are synchronized with their associated server(s). This architecture requires a huge server storage capacity and fast data access to support a typically large client base. As the client base continues to grow over time, it becomes increasing difficult to provide a large storage quota on the server for each client.
The server is responsible for managing a large number of accounts associated with the clients it serves. As the number of clients and associated accounts grow, maintaining a workable storage allotment for each client becomes problematic, requiring ever increasing hardware resources and increased expense. As clients begin to reach their storage limits, they may be required to spend time managing their account through periodically archiving data, and possibly establishing smart rules to help handle the storage load. However, once account items are moved to an archive, a majority of the online useful functionalities for those items is lost.
Another aspect compounding this problem is that a user may access his or her account from more than one client. The user may access his or her account from a desktop computer or laptop computer while in the office, a home computer or laptop computer when at home, or a personal digital assistant (“PDA”), laptop computer, or other portable computing device when traveling. Synchronization between the different clients can be problematic.
Analysis has shown that an average of between 70-80% of the storage space in a typical account is consumed by attachments for items stored in the account. These attached files and/or other types of attachments are the major consumers of space allotted for the account. For example, in a typical email server/client case a typical text/html email message without any attachments may require around two KB of memory, while the size of an average attachment requires around one MB of memory. Statistically, if the one MB attachment were removed, additional space would be freed up for storing approximately 600 more email messages. This condition is even worse if the mailbox contains multimedia attachments to the emails. Multimedia attachments are typically meant to be viewed once and deleted, but in most cases, they remain in the mailbox holding storage space equivalent to thousand of email messages. Also, users often tend to be undisciplined with management of the emails, such that the mailbox size may reach the maximum limit at inopportune times, forcing the user to stop what they are doing in order to delete or archive messages from their mailbox so that they can receive new items. Typically clients work on a single off-line data file, like an “.ost” file for Microsoft® Outlook®. This file grows with mailbox storage usage and the off-line features that are set. Working with such a single large off-line data file does not deliver high client performance. Also, this situation is not highly scalable.